linux应急响应
最近在进行应急响应时遇到linux系统比较多,之前在对linux系统进行排查的时候,没有一个严谨的流程,导致在溯源分析的过程比较混乱,常常一个命令运行多遍。所以就想对linux系统的应急进行一下总结,具体需要排查哪些方面和使用哪些命令,流程是怎样的。
linux出现问题主要是病毒挖矿和webshell植入两种场景,我们就从这两种场景分别进行总结。
病毒挖矿
在接到应急的项目后。我们在到达现场,首先需要和客户沟通如下内容:服务器是否存在Web服务,服务器的口令强弱,服务器的网络架构。沟通的目的在于了解挖矿病毒是由什么方式植入,如果是存在Web服务,需要进一步对Web服务进行排查,口令强弱在于可能会利用ssh弱口令直接登录后植入,网络架构的了解是为了存不存在横向移动的风险。对这些内容了解后,我们开始进行具体的排查步骤。
进程服务相关
top
1.挖矿病毒典型的特征的是CPU占用率高,所以我们第一使用Top命令来查看。
可以看到目前的CPU的占用率已经高达97.7%,说明这个程序确实存在问题。
对于top命令,我们关注的点主要有以下几点:1.用户,2.cpu信息,3.时间
用户主要是在top命令最上一行,可以看到目前是1个用户,cpu信息主要关注cpu占用率,进程执行数量,还有时间信息,时间信息代表运行的时间总时长,可以从这里推断病毒植入时间,同时也方便我们查看日志时有目标的去寻找信息。
ls -al /proc/[pid]/exe
2.定位异常文件,我们在Top命令中发现一个异常进程,接着我们就需要定位他的位置,使用命令ls -al /proc/11134/exe来定位进程的文件位置
这条命令可以看到进程所对应的文件位置,同时也能看到程序运行的开始时间,定位在文件位置后,我们ls -al [文件],可以看到文件创建的时间。
netstat -antp
3.使用netstat -antp查看当前外联情况,我们一般需要看的状态为已连接状态也就是ESTABLISHED,同时对应PID的值来看。可以看到这里存在之前占用CPU高的可疑程序外联的一个IP地址,我们在威胁情报中查询一下这个地址。
在威胁情报中已经收录此地址,为一个矿池地址,这里我们可以初步确定为挖矿程序。
strings
一般来说,在发现挖矿安全事件客户首先做的事断网处理,并且服务器也不会让插入介质,所以我们对可疑程序不能快速的上传至云沙箱中分析,这里就借助Strings命令简单的查看一下文件内容。对于文件内容主要进行关键字筛选集中在pool,pool.,tcp,wallet等。大部分程序会存有钱包地址,地址池地址等。我们通过strings可以看到存在poolwallet,pool.hashvault.pro关键字,且pool.hashvault.pro已经被标记为矿池地址,所以直接能够确定此程序为挖矿程序。
lsof -p [pid]
对于已经确定为病毒程序文件,我们还是先不要着急去kill进程,需要对进程近一步的进行分析,从而防止我们后续无法干净清除病毒程序。lsof -p 11303查看病毒进程调用的所有文件。这里我们可以看到此程序调用的文件较少,无异常文件。
systemctl status pid
这里还需要查询程序是否存在守护进程,如果刚才上面我们直接kill掉进程,挖矿病毒程序还会重新自启动。使用命令systemctl status 11303 ,可以看到未存在守护进程。对于有守护进程的病毒程序,先要kill掉守护进程,接着再kill掉挖矿进程。
crontab -l
经过上面一系列操作,我们已经能找到挖矿病毒程序所有相关的内容,但是我们还需要进一步去确认有无残留的权限维持的相关内容。crontab -l 枚举定时任务,这里我们可以看到并无任何定时任务。
systemctl list-unit-files
对于自启动服务我们同样需要关心,使用systemctl list-unit-files | grep enabled来筛选开机自启动的服务。如果存在与挖矿病毒相关的自启服务,使用命令systemctl disable 服务名关闭。我们需要关注systemd 配置文件:
①/etc/systemd/system 存放系统启动的默认级别及启动的unit的软连接,优先级最高。
②/run/systemd/system,系统执行过程中产生的服务脚本,优先级次之。
③/usr/lib/systemd/system 存放系统上所有的启动文件。优先级最低
时间允许的话可以分别查看这3个文件夹的文件。
user相关
awk -F: ‘$3==0{print $1}’ /etc/passwd
我们检查完服务,进程后,还需要对用户进行检查,防止二次被植入病毒程序。使用awk -F: ‘$3==0{print $1}’ /etc/passwd命令来查询特权用户。
cat /etc/passwd | grep -v nologin
查询除无法登录以外的用户,有无新增cat /etc/passwd | grep -v nologin。
awk ‘/$1|$6/{print $1}’ /etc/shadow
查询可以远程登录的帐号信息,awk ‘/$1|$6/{print $1}’ /etc/shadow。
/var/log相关
在对整个服务器进行检查完成后,还需要对日志进行分析,来还原攻击
/var/log/btmp
登陆失败的用户日志一般存储在/var/log/btmp中,使用lastb可以进行查看。
/var/log/lastlog
所有用户登陆日志在 /var/log/lastlog中,可以使用lastlog来查看
/var/log/wtmp
系统的成功登录、关机、重启等会存储在 /var/log/wtmp中,使用命令 last可以查看。
/var/log/auth
这里需要注意的ubuntu的用户认证日志存储在/var/log/auth.log中,而centos的用户认证日志存储在/var/log/secure中,使用命令cat /var/log/auth.log | grep -i “accepted password”筛选登录成功的日志信息。
使用命令可以查看cat /var/log/auth.log | grep -i “failure”筛选登录失败日志
对于想查看SSH爆破使用命令cat /var/log/secure|awk ‘/Failed/{print $(NF-3)}’|sort|uniq -c|awk ‘{print $2”=”$1;}’可来筛选出来次数,进行一个分辨。从下面可以明显的看到被爆破的痕迹。
/var/log/wtmp
查看机器创建以来登陆过的用户,使用last命令查看。
history
其实history局限性很大,我们看到的history只是SSH连接后的产生记录,对于使用nc,shell,脚本等执行的一些命令是不会记录出来的。从下面可以看到我们只能看到反弹shell命令,具体反弹后输入了什么命令history是不做记录的。
history | more 带时间显示
.bash_history
上面我们提到history的局限性比较大,所以我们需要结合.bash_history的命令一起来看历史的操作命令。
以上是对病毒挖矿应急响应的一个整体流程与命令,基本上是能够将所有的风险项都检测出来,但实际的应急过程中,常常还会被客户单位问一个问题(针对没有web服务的客户单位):本单位的服务器对外发起的攻击怎么查?其实刚开始对于这个问题自己表示也很懵,除了看历史命令就没有什么方式去看,其实还可以从流量特征方面去分析是否对外发起过攻击,但是具体是什么攻击确实没有方法去看。除非是服务器上留存一些扫描攻击或漏洞利用工具。这里再引入一点,如果发现服务器日志被删除掉,可以进行恢复。
假设我们服务器现在被删除了auth.log与auth.log.1日志文件
第一步先查看文件对应的PID值:lsof | grep auth.log,可以看到PID的值为420,文件对应的描述号为7。
第二步在/proc下找对应的文件:ls -al /proc/420/fd/7
第三步将文件从/proc/420/fd/7拷贝到/var/log/auth.log:cp /proc/420/fd/7 /var/log/auth.log
这样文件就被恢复了,但是需要记得的是,如果使用命令cat /dev/null > /var/log/文件名这种方式的话,是无法进行恢复的。
webshell植入
对于webshell植入类型的应急响应,我们需要的是注意三点,第一点是对网站根目录下所有的文件进行排查,防止留存木马;第二点是对服务器进行排查,防止留存后门;第三点是需要排查清楚通过什么漏洞入侵进的服务器。
首先我们需要了解各中间件日志存放的位置:
weblogic
weblogic会有3种日志,分别是accesslog,Server log和domain log。
对于weblogic的日志位置一般在weblogic安装目录\user_projects\domains\下
tomcat
tomcat日志一般存放在:tomcat安装目录/logs下
如果在logs下未找到,可以在conf/logging.properties查看存放的位置
apache
apache日志一般存放在网站根目录下,要是没有找到可以从httpd.conf配置文件中找:
grep -i”CustomLog” /etc/httpd/conf/httpd.conf
grep -i”ErrorLog” /etc/httpd/conf/httpd.conf
nginx
nginx的日志位置可以从nginx根目录下去找,或者在nginx目录下找到nginx.conf文件来看ningx的日志路径。
如果找到不到nginx.conf文件,先定位nginx进程ps -ef | grep nginx找到目录后,在目录文件下寻找具体文件即可。
Mysql数据库
linux系统下主要以安装mysql为主,为了数据安全,同样还是得查看数据库日志。
先使用SHOW VARIABLES LIKE ‘gen%’;查看数据库操作状态以及操作日志存放的位置,默认general_log是关闭的。
通过位置我们查看日志信息,可以看到其实记录还是很全面的,包括执行过的命令,连接过的IP,对数据库的操作。
同时也会记录对数据库爆破操作。所以,我们的在日常运维的过程中一定要开启日志记录。
使用show full processlist;查看正在对数据库的连接。
示例
这里我们以Tomcat为例,前面我们也提到tomcat的日志的位置,我们直接看日志,发现其中一个IP地址,对/manager/status页面进行爆破(时间间隔短),这个页面也就是tomcat-mangaer页面。
/tomcat/log

在经过尝试后,还是登录成功,应该是爆出来用户名密码,接着在/manager/html/list进行了文件上传,并且上传成功。
紧接着对shell/shell.jsp进行了访问。到这里可以分析到利用了tomcat-manage页面进行口令爆破,同时上传了webshell,进行了连接。
在catalina.log中同样能看到爆破过程。
接着我们去寻找shell位置,tomcat上传的shell一般会在webapps下面,可以看到shell.jsp的文件。
这里我们只是找到一个shell.jsp的文件,我们还需要查找其他的目录是否存在Webshell。
find /目录 -name ‘文件关键字‘
find /usr/local/tomcat -name ‘jsp‘
这里将tomcat目录下所有jsp文件全部罗列出来。
对于这么多jsp文件,我们其实会很没有耐心去一个一个文件看,所以就需要更深的检索。
find /目录 -name ‘文件关键字‘ -ls
将所有的jsp文件的详细信息罗列出来,这样也更方便我们去进行通过每个文件的具体信息来进行排查。
但是在有些时候,项目文件太多,这种方式又显的很笨拙,所以需要进一步再进行命令优化。
find /目录 -name ‘文件关键字‘ -命令集
find /目录 -name ‘文件关键字‘ -amin -10 查找在系统中最后10钟访问的文件
find /目录 -name ‘文件关键字‘ -atime -2 查找在系统中最后48小时访问的文件
find /目录 -name ‘文件关键字‘ -mmin -5 查找在系统中最后5 分钟里修改过的文件
find /目录 -name ‘文件关键字‘ -mtime -1 查找在系统中最后24 小时里修改过的文件
我们查找下最后12小时内修改过的文件,搜索范围又变小了,再结合入侵的时间点,还是相对比较容易找出其他的木马程序。
其实在linux中,还有很多命令去组合进行搜索,找到适合自己的一套搜索命令更能快速去进行问题的排查。后面的排查还需要对服务器进行一个排查,防止对方留存后门程序进行一个持久化的控制。后续的排查过程可以与我们对病毒挖矿类的响应过程进行排查。
总结
在我们进行应急响应的过程中,无论是遇到什么情况,都需要记住,首先和客户需要进行详细的沟通,确认网络环境,确认什么事件。在能够断网的情况下尽量做到断网排查,第一时间不要去着急结束相关进程和删除文件操作,防止后面有些点溯源不到位的情况。其次,我们在做的每一步对文件的操作,拍照或截图留存证据,对于溯源的过程也需要进行证据留存。在排查的过程中,一定要做到细致,不要放过任何的可疑文件,对于一些可疑的进程或程序,追踪他的进程链条总能去判断此程序的可疑性。

